Please invest more time in grep and replace "mlx5" suffix.

It is very unfortunate that you relied on mlx5 provider, it is not very good example to follow.

Thanks

Hi, Leon,

Thank you for your feedback.

In the early stages, we relied heavily on the mlx code and design, which helped get our device up and running quickly. We're now incorporating our own logic and gradually phasing out the mlx code, though it's clear we haven't fully succeeded yet.

I’d like to ask if our code is being rejected due to high duplication with existing code. I understand that our driver must first be merged into the Linux kernel before patches like ours can be accepted. If that's already done, is our rdma-core provider code, in its current state, eligible for inclusion in the rdma-core mainline?

Hi, Leon,

Thank you for your feedback.

In the early stages, we relied heavily on the mlx code and design, which helped get our device up and running quickly. We're now incorporating our own logic and gradually phasing out the mlx code, though it's clear we haven't fully succeeded yet.

I’d like to ask if our code is being rejected due to high duplication with existing code. I understand that our driver must first be merged into the Linux kernel before patches like ours can be accepted. If that's already done, is our rdma-core provider code, in its current state, eligible for inclusion in the rdma-core mainline?

It is not rejected but delayed till we will get and merge Linux kernel part of that driver. There is no real benefit in reviewing the rdma-core code now as it has so many mlx5 specific code. For example all ENV variables should go. In addition, you will need to post your rdma-core code to linux-rdma mailing list too as we are requiring to do so from new drivers.

Thanks